Skip to content

Fixes an off-by-one error in checkpoint restores during replay playback#18259

Closed
JoeOsborn wants to merge 2 commits intolibretro:masterfrom
JoeOsborn:bsv-fix-checkpoint-desync
Closed

Fixes an off-by-one error in checkpoint restores during replay playback#18259
JoeOsborn wants to merge 2 commits intolibretro:masterfrom
JoeOsborn:bsv-fix-checkpoint-desync

Conversation

@JoeOsborn
Copy link
Copy Markdown
Contributor

The issue was that when recording, the recorded checkpoint incorporates the current frame's inputs. But when playing back, the checkpoint was deserialized before the current frame was simulated. The fix was to serialize the current frame at the beginning of the frame, before inputs were applied, during recording. An alternative fix would be to defer deserializing the frame until after the next frame is simulated, but that seemed more complicated. A frame (including checkpoint) now means "the inputs of frame K and, if a checkpoint, the state as of the beginning of frame K".

If the maintainers would prefer that a replay checkpoint means "The inputs of frame K and the state as of the end of frame K" I could make that change instead.

Either solution should account for the "jank" I experienced in some cores which were particularly sensitive to the offset.

The change in msgqueue is an unrelated fix that I needed so I could run GDB without erroring out on a use-after-free.

I had to fix this so I could use address sanitizer + gdb to debug a
different problem.
The issue was that when recording, the recorded checkpoint
incorporates the current frame's inputs.  But when playing back, the
checkpoint was deserialized *before* the current frame was simulated.
@JoeOsborn JoeOsborn closed this Sep 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant